Условное название: Local Sender Policy или Локальные политики для отправителя
Назначение: дополнение или переопределение политик в отношении адреса отправителя, определяемых глобально (SPF)
Описание: Local Sender Policy (далее — LSP) проверяются перед вызовом SPF; последняя может вообще не использоваться. Проверка основана на анализе сочетания IP-адреса клиентского подключения, имени узла (хоста), переданного в команде HELO, и адреса отправителя (MAIL FROM). LSP хранятся в текстовом списке следующего формата:
1 (IP_MASK) - шаблон IP-адреса
2 (NOT_1) - признак проверки на несовпадение
3 (INCOMINGHOST) - шаблон имени клиентского узла
4 (MODE) - статус переданного имени узла:
M - имя соответствует IP-адресу подключения (найдено в DNS)
U - имя не соответствует IP-адресу подключения (найдено в DNS)
E - имя не найдено в DNS
пусто - соответствует MEU
5 (NOT_2) - признак проверки на несовпадение
6 (EMAIL) - шаблон почтового адреса
7 (NOT_3) - признак проверки на несовпадение
8 (G_NOT) - признак общей инверсии результата
9 (RESULT) - код политики:
AM (Accept Matched) - сочетание признано истинным,
дополнительная проверка не требуется
RF (Reject Forged) - сочетание признано невозможным, адрес
подделан, дополнительная проверка не требуется
FA (FAil) - требуется дополнительная проверка,
отказать при уровне FAIL
SF (SoftFail) - требуется дополнительная проверка,
отказать при уровне SOFTFAIL
NE (NEutral) - требуется дополнительная проверка,
отказать при уровне NEUTRAL
Список, как обычно, просматривается сверху вниз. Поля 1, 3 и 6 — обычные шаблоны, которые могут содержать символы групповой операции * и ?. Если какое-то поле пустое, проверка не производится, флаг NOT_? не проверяется, соответствующее условие считается истинным. Все три условия объединяются по И, общий результат может быть инвертирован, если установлен флаг G_NOT. Если в результате получилась истина, анализ списка прерывается и фиксируется код политики. Если проверяемое сочетание не попало в список, используется политика по умолчанию FA. Если зафиксирован код RF, адрес отправителя отвергается без дополнительных проверок. Если зафиксирован код AM, SPF не вызывается (экономим время и трафик). Во остальных случаях выясняется глобальная политика, если включена соответствующая опция.
Замечание. Включение разрешительной политики не отменяет прочих проверок, поскольку политики определяют вероятность подделки адреса, но не принадлежность его к чёрным или белым спискам.
Итак, ваши соображения?
Идея не плохая, но:
- Для "белых списков SPF" слишком накручено (хотя запас гибкости лишним не будет
)
- Как самостоятельная (замена SPF, YDK) будет слабовата, так как
а) все заполненение ложится на плечи администратора, поиск по логу, заполненеи таблицы, а это тоже время, которое будет тратить SPF на получение данных по DNS. б) на диалапщиках будет неэфективно, списки будут постоянно расти.
Но в целом я "ЗА". Меня такой "белый список" SPF + RBL! (думаю, действия статуса LSP хорошо бы распространять на все политики: RBL, SPF, YDK — такую "зону охвата" можно регулиовать доп. полем) вполне устраиваетУ меня есть надежда, что этот список десятком — другим строк заменит изрядную часть моих чёрных списков. Особенно учитывая, что косяком пошёл спам от имени Спамтеста и Subscribe.ru.
Про обход YDK подумаю, а RBL у меня отрабатывает раньше — правда, блокировка отложенная и может быть отменена белыми списками.
Читали мою дискуссию с Тутубалиным на spamtest на эту тему? (ссылка на AntiSpamNews). Подделка под subscribe.ru с обратным адресом subscribe.ru на 100% фильтруется SPF, т.к. у subscribe.ru жесткая SPF-политика. Поэтому в этих подделках обратным адресом ставят spamtest.ru, которые идеологически несовместимы с SPF... Фактически можно просто ставить spamtest.ru в черный список отправителей без отрицательных последствий. Или применять комбинированный фильтр по mail from и From:. Я с этим не заморачиваюсь особо, т.к. PopFile проблему спама решает все-таки на порядок лучше всех остальным методов вместе взятых. Только когда вместо традиционного спама начнуть слать литературные произведения, без намека на продажи
А у контекстных проверяльщиков один минус на всех — письмо надо принять. Хорошо хоть, что сами письма невелики.
P.S. Кстати, в "родном" SPF есть, по-моему, небольшая логическая нестыковка. Если результат pass, то письмо идёт мимо PopFile (потому что задан MESSAGE-CLASS). Мне это правильным не кажется — даже если PeerIP & MAIL FROM допустимы политиками домена, это ещё не значит, что сам отправитель настолько надёжен.
"\ 7. Не проверяем письма, если MESSAGE-CLASS уже установлен ранее (например, by spf)" в IsSpam.rules.txt. А потому что SPF не устанавливает класс, если он не был установлен до него, а только "перебивает" ранее установленный:
SPF_RESULT =~ pass | MESSAGE-CLASS NIP | S" spf_pass" SetMessageClass FALSE \EOF
А поскольку до SPF-проверки никто классификацией в конфиге по умолчанию и не занимается, то эти строки и остаются ружьем, висящим на стенке... В общем, пока оставим как есть.
Кстати, по тому же отчету получилось, что из 20 000 писем, дошедших у нас до стадии классификации PopFile в этом месяце, спам составляет 93%. В который раз убеждаюсь, что без PopFile мне давно пришлось бы уже отказаться от старых почтовых ящиков.
Уже стрельнуло.
Понравилась мне классификация писем (в основном отбитых) и прописал в разные места типа RCPTTO.rules.txt слова:
RCPTTO GetUserFromEmail SMTP[DenyLocalPartCharacters] CharsInSet | S" ErrCharSet " SetMessageClass " 550 {RCPTTO} wrong local part ({uDeniedChar 1}){CRLF}" RcptToError
B log.str.txt прописал:
920 *{Dirs[Logs]}\smtp\{YYYYMM}mail-refused.txt*{YYYY-MM-DD} {hh:mm:ss}; {MESSAGE-CLASS} ;{MAILFROM};{RCPTTO};{MESSAGE-SIZE};{H-MESSAGE-ID HSKIP};{CLIENT};
И в логе получилось очень красиво:
2005-02-11 13:04:34; RBL_Block ;;ule@pantv.ru;0;;203.82.64.131;
2005-02-11 13:04:57; spam ;apt@louiskoo.com;tanya@pantv.ru;10748;<7e1f01c51049$d9abf150$f279e0b7@louiskoo.com>;201.17.57.160;
2005-02-11 13:05:04; RBL_Block ;;ule@pantv.ru;0;;203.82.64.131;
2005-02-11 13:05:56; NoSuchUser ;lfw@beep.ru;spera@pantv.ru;0;;67.171.142.189;
2005-02-11 13:07:22; NoDom_Send ;detleff@mexxxico.com ;;0;;61.83.250.18;
2005-02-11 13:07:22; virus ;terorista@mail.ru;maket@pantv.ru;27634;<scjveqkrkncnoqbmzud@pantv.ru>;81.20.170.198;
Очень удобно получилось. Сразу видно почему письмо отбито.
Только после каждого обновления куча правки
Может это как постоянную фичу сделать?
Да, наверное для такого использования я это условие и задумывал
Эта фича в PigMail давно существует. По вашей, кстати, заявке. И ключик у вас есть.
Совсем дурной вариант: политика WL включает и обход YDK тоже. Как обычно, имеются варианты: либо это делается одним общим с другими противоспамными фильтрами флагом (соответственно, вылезать будет из различных мест), либо флаг выставляется отдельный (тогда вопрос — дорабатывать ли белые списки под новую фичу? и не завести ли ещё пару политик, позволяющих отключать PopFile и YDK по отдельности?). Склоняюсь к первому — во-первых, проще (гораздо), во-вторых, весь антиспам рулится по одним правилам.